Release Mismanagement in Open Source

To a user, unreleased software is nonexistent software, even in open source projects which make the source code readily accessible. Every project requires regular software releases to encourage adoption and attract developers. Different projects approach the task of releasing software in various ways [2], and many experience breakdowns in their release process at some point during their evolution [3]. This poster presents examples of these instances, and how projects are learning from and improving upon them. During the FreeBSD 5.x release cycle, the developers set very aggressive goals for the upcoming release [1]. Each of the goals was a large feature unto itself, and when combined, they caused the release cycle to stretch much longer than anticipated. The stabilization process proved difficult, due to the widespread impact of these features. When these features eventually were released, it took several rounds of bugfixing to produce a result which satisfied the community. In June 2008, the Subversion development team released Subversion 1.5.0. This release contained a number of new features, but arrived only after a long and difficult development, test and release cycle. This protracted process confused and frustrated both users and developers. The Subversion developers are currently working to learn from this experience and improve their process in the future. This research looks at the events which led to these and other breakdowns, how the release processes could be improved, and what lessons other open source and proprietary projects can learn from these mistakes.